AWS DataSync タスクのログ設定違いと、タスク実行エラーの検知方法を確認してみた
AWS DataSyncを利用しエージェントが不要なリソース間でのデータ転送していました。タスクにエラーが起きてタスクが失敗した際に有用そうな設定は何か気になったので確認してみました。
タスクのログ設定が2種類あったので出力結果の違いを見比べてみます。その後、タスクでエラーが起きた際の通知方法を試してみます。
検証環境
本記事のDatasSyncのタスク設定は東京リージョン（ap-northeast-1）にあるEFSのデータを大阪リージョン（ap-northeast-3）にあるS3へデータを同期しています。
以下のリンクで作成した環境です。
ログ設定
DatasSyncのタスク設定で出力するログレベルをBasicか、Allを選択できます。
Log all transferred objects and files
Allから試してみます。現在以下のディレクトリ内容でデータ転送済みです。
$ ll 合計 12 -rw-rw-r-- 1 ec2-user ec2-user 0 11月 4 12:05 test1.txt -rw-rw-r-- 1 ec2-user ec2-user 0 11月 4 12:05 test2.txt -rw-rw-r-- 1 ec2-user ec2-user 0 11月 4 12:05 test3.txt
すべて削除します。
$ rm *.txt
テストファイルを作成します。
$ touch logAll-1.txt logAll-2.txt logAll-3.txt
$ ll 合計 12 -rw-rw-r-- 1 ec2-user ec2-user 0 11月 5 12:14 logAll-1.txt -rw-rw-r-- 1 ec2-user ec2-user 0 11月 5 12:14 logAll-2.txt -rw-rw-r-- 1 ec2-user ec2-user 0 11月 5 12:14 logAll-3.txt
タスクを手動実行しデータ同期に成功しました。
CloudWatch Logsの結果
CloudWatch Logsに保存されたログの内容です。削除されたファイル名、転送したファイル名が記録されています。トラブルシューティング目的に記録しておくのは非常に有用そうです。 タスク実行の度にファイル数の増減が非常に多いシステムですと、ログ量も比例して増加しCloudWatch Logs利用費が多少気がかりです。
----------------------------------------------------------------------------------------- | timestamp | message | |---------------|-----------------------------------------------------------------------| | 1636114164977 | [INFO] Execution exec-06fd9fe310192d0b4 started. | | 1636114172796 | [NOTICE] rm /test1.txt | | 1636114172796 | [NOTICE] rm /test3.txt | | 1636114172796 | [NOTICE] rm /test2.txt | | 1636114172824 | [NOTICE] Removed /test2.txt | | 1636114172843 | [NOTICE] Removed /test3.txt | | 1636114172848 | [NOTICE] Removed /test1.txt | | 1636114173664 | [NOTICE] Transferred file /logAll-2.txt, 0 bytes | | 1636114173664 | [NOTICE] Transferred file /logAll-3.txt, 0 bytes | | 1636114173664 | [NOTICE] Transferred file /logAll-1.txt, 0 bytes | | 1636114180475 | [NOTICE] Verified file /logAll-1.txt, 0 bytes | | 1636114180475 | [NOTICE] Verified file /logAll-2.txt, 0 bytes | | 1636114180475 | [NOTICE] Verified file /logAll-3.txt, 0 bytes | | 1636114181007 | [INFO] Execution exec-06fd9fe310192d0b4 finished with status Success. | -----------------------------------------------------------------------------------------
Log basic information such as transfer errors
次はBasicです。またすべて削除します。
$ rm *.txt
テストファイルを作成します。
$ touch logBasic-1.txt logBasic-2.txt logBasic-3.txt
$ ll 合計 12 -rw-rw-r-- 1 ec2-user ec2-user 0 11月 5 12:23 logBasic-1.txt -rw-rw-r-- 1 ec2-user ec2-user 0 11月 5 12:23 logBasic-2.txt -rw-rw-r-- 1 ec2-user ec2-user 0 11月 5 12:23 logBasic-3.txt
タスクを手動実行しデータ同期に成功しました。
CloudWatch Logsの結果
変更あったファイル名、転送したファイル名が記録されません。トラブルの種類にもよりますがトラブルシューティングするときログから原因を追うのは難しそうです。
----------------------------------------------------------------------------------------------------------------------------- | timestamp | message | |---------------|-----------------------------------------------------------------------------------------------------------| | 1636114994756 | [INFO] Request to start task-0c9c3100c88096a14. | | 1636115128875 | [INFO] Started logging in destination hostId: host-0c2434f03167678b6 for Execution exec-07737854023fdd92a | | 1636115129185 | [INFO] Started logging in destination hostId: host-0f6e9ee984e9f0cd6 for Execution exec-07737854023fdd92a | | 1636115129199 | [INFO] Execution exec-07737854023fdd92a started. | | 1636115139023 | [INFO] Execution exec-07737854023fdd92a finished with status Success. | -----------------------------------------------------------------------------------------------------------------------------
タスク実行エラーの検知
以下の様にタスク実行時にエラーが起きた場合の検知、通知方法を考えてみます。
CloudWatch Logs
さきほどのCloudWatch Logsのログ内容からエラーを確認できるのかタスクエラー時のログを確認します。
Log basic information such as transfer errors
今度はBasicから確認します。
finished with status Success.のログを記録されていないため成功していないことはわかります。The source contains no files.エラーの原因はログに記録されますが、[INFO]と表示されておりCloudWatch メトリクスフィルターでエラーがあったことを拾うのは厳しそうですね。
----------------------------------------------------------------------------------------------------------------------------- | timestamp | message | |---------------|-----------------------------------------------------------------------------------------------------------| | 1636116641437 | [INFO] Request to start task-0c9c3100c88096a14. | | 1636116749419 | [INFO] Execution exec-0b8f24e6e4ede2b5f started. | | 1636116749500 | [INFO] Started logging in destination hostId: host-010e3f160a142205d for Execution exec-0b8f24e6e4ede2b5f | | 1636116749758 | [INFO] Started logging in destination hostId: host-013e2f12b8a21c689 for Execution exec-0b8f24e6e4ede2b5f | | 1636116751508 | [INFO] Execution exec-0b8f24e6e4ede2b5f finished with status The source contains no files. | -----------------------------------------------------------------------------------------------------------------------------
Log all transferred objects and files
次はALLです。ログの出力内容に変化はありませんでした。
----------------------------------------------------------------------------------------------------------------------------- | timestamp | message | |---------------|-----------------------------------------------------------------------------------------------------------| | 1636117025963 | [INFO] Request to start task-0c9c3100c88096a14. | | 1636117168716 | [INFO] Execution exec-062e7c14b3de519d8 started. | | 1636117168748 | [INFO] Started logging in destination hostId: host-0224d7932aaf4df3d for Execution exec-062e7c14b3de519d8 | | 1636117168987 | [INFO] Started logging in destination hostId: host-074dfd0813a130f47 for Execution exec-062e7c14b3de519d8 | | 1636117170692 | [INFO] Execution exec-062e7c14b3de519d8 finished with status The source contains no files. | -----------------------------------------------------------------------------------------------------------------------------
CloudWatch Logsからのアラート通知はあきらめます。
EventBridgeで検知
EventBridgeのルール設定でDataSyncの状態変化を検知し通知を作ることができるとドキュメントから読み取れます。
EventBridgeのイベントパターンでERRORを検知するようにしてみました。サンプルのテンプレートを載せておきます。この設定は特定タスクのエラーに限定していません。状態がERRORのタスクすべてに反応します。
AWSTemplateFormatVersion: "2010-09-09"
Resources:
EventsRule1:
Type: "AWS::Events::Rule"
Properties:
Name: "sample-datasync-error-rule"
EventPattern: |
{
"source": ["aws.datasync"],
"detail-type": ["DataSync Task Execution State Change"],
"detail": {
"State": ["ERROR"]
}
}
EventBusName: "default"
ターゲットは任意の送信先を設定してください。テンプレートでは指定していません。キャプチャは通知テストにSNSトピックを設定した例です。SNSでのメール通知と、ChatbotでのSlack通知を試してみます。
メール通知
JSONを整形すると多少見やすくなります。タスクID（task-0c9c3100c88096a14）を見てもいまいち何の設定しているタスクかわかりません。でもERRORがあったことはわかります。通知をトリガーにマネージメントコンソールからDatasSyncのHistoryを確認し、詳細を確認した方が早そうですね。
{
"version": "0",
"id": "c1982cbf-62a3-5b00-5f73-6f0075114576",
"detail-type": "DataSync Task Execution State Change",
"source": "aws.datasync",
"account": "123456789012",
"time": "2021-11-05T13:56:39Z",
"region": "ap-northeast-1",
"resources": [
"arn:aws:datasync:ap-northeast-1:123456789012:task/task-0c9c3100c88096a14/execution/exec-0086e84f4dc65fbe8"
],
"detail": {
"State": "ERROR"
}
}
2022/3/25追記メール通知内容の整形など紹介している以下のエントリもご参考に
AWS ChatbotでSlack通知
ERRORなのかわかりませんが状態に変化があったことはわかります。
EventBrigedで設定したイベントパターンはERROR以外の状態では通知は飛びません。とは言えどERRORの文字列は確認できない...
おわりに
エラー通知が必要ならEventBridgeからの通知設定と、トラブルシューティングのためにログ設定はは可能ならAllが望ましいといった感想です。ファイルの変更が多いとログ量が増えますのでCloudWatch Logs利用費は設定後確認された方がよろしいかと思います。
